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ABSTRACT 


This thesis develops a concept for integrating decision support technologies with 
global computer networks. It introduces a new paradigm for the distribution and use 
of algorithms, decision support applications, models, and simulations. Under this 
paradigm, all mechanisms to allow for interactions between providers of tech- 
nologies and consumers who wish to use them are facilitated by a distributed decision 
support server. Additionally, this thesis analyzes the concept of distributing decision 
technologies as a service vice a software product. It develops the initial framework 
architecture and proposes an infrastructure for a distributed decision support network. 

Decision support systems have traditionally been developed as stand alone 
applications which conform to a specific users hardware and software requirements. 
This leads to reduced sharing and reuse of the application as well as the data, models, 
and algorithms incorporated within the application. The Internet, WWW, and 
enabling technologies allow for the dissemination of multimedia information to 
support diverse groups of remote users. This thesis demonstrates that decision 
support technologies can also be made available to users of a heterogeneous network 


in a similar manner. 
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I. INTRODUCTION 


“Defense modeling and simulation will provide readily available, operationally valid 
environments...to train jointly,...formulate operational plans, and assess warfighting 
situations.” DoD EXCIMS, 

March 1992 


“We have the following strategic requirements for Modeling and Simulation... direct 
interface capability with operational C4I systems (comms, ADP, ADA)” 
Brig Gen Michael C. Short, USAF 
Director of Training, U.S. Atlantic Command 
November 1993 


“The organization that will excel ... will be those that manage information as a major 
resource” (Synott, 1981) 


A. BACKGROUND 

The purpose of this thesis is to develop a framework architecture for the distribution 
of decision sipporl technologies’ in a client server environment over a network using 
Transmission Control Protocol/Internet Protocol (TCP/IP). The open architecture design of 
TCP/IP has enabled the dissemination of information over a global network through the use 
of Network Information Discovery and Retrieval (NIDR) tools such as SMTP, FTP, WAIS, 
and TCP/IP applications such as Telnet and Network news. (Sprague, et al., 1993) These 
tools provide for a friendly user interface for the transfer of electronic information. The 
World Wide Web (WWW) has allowed the functionalities of these different applications to 
be combined under a single integrated browser application. (Berners-Lee, et al., 1994) By 
means of a simple scripting language the functionalities of these applications are now being 


used in conjunction with other software applications. The HyperText Transfer Protocol 


‘Throughout this thesis, decision support technologies and decision technologies 
are used to refer to a variety of software used to support decision making and modeling. 





(HTTP) and HyperText Mark-up Language (HTML) has created an opportunity to exploit 
the functionalities of TCP/IP applications. (Berners-Lee, 1993) 

The use of computer support to aid in decision making is required in many situations 
due to the volume of data and/or the time sensitive nature of the decision. Development of 
an application specific DSS is a lengthy and costly process. The models and algorithms 
must be verified and validated with valid data sets. Applications are continuously updated 
due to changes in the environment, changes in data requirements, and development of better 
algorithms. The life of a decision technology is usually short, as it is may only support one 
specific decision. This technology is thus archived and the models and algorithms used 
within the technology are lost and unavailable to users that may need to make the same or 
similar decision. Many organizations feel that it is not cost effective to buy or build DSS’s 
for a specific decision process. (Sprague, 1980) This suggests that some applications may 
be better served as a service rather than a product. The customer could use the application 
and not be concerned with the management issues associated with owning the software 
product. This service could be provided by constructing a Distributed Decision Support 
Network (DDSN) which would allow a consumer to connect to and execute an application 
through simple hypertext links or a Graphical User Interface (GUI). 

Industry and the Department of Defense (DoD) are moving rapidly to distributed 
systems, common operating environments, client server configurations, and object oriented 
databases. (Kral, January 1995) These technology upgrades will preclude the use of 
legacy/standalone decision technologies by all users of the distributed environment. To take 
full advantage of new technology, existing tools will need to be re-engineered to operate 
within the new operating environment. This is likely to be a timely and costly evolution. 

An alternate solution would be to distribute the existing legacy DSS applications/tools to 


users of the distributed network. 


B. OBJECTIVES 
The goal of this thesis is to outline an architecture and propose an infrastructure to 


facilitate the distribution of decision technologies over a global network. This is done by 








establishing the idea and concepts of operation of the DDSN; identifying the functionality 
required between all entities of the system; and modeling the activities associated with the 
distribution of decision technologies. Through a rapid prototyping methodology, the 
responsibilities and transactions of all entities of the DDSN, will be substantiated. Once the 
architecture is developed, it is the authors intent to identify current capabilities and initiatives 
that relate to the architecture proposed, and to suggest areas where this technology can best 


be exploited by organizations in commercial industry and the DOD. 


c ORGANIZATION OF THESIS 

This thesis is organized into six chapters and two appendices. 

The first chapter contains the introduction and overview of this thesis. The second 
chapter conveys the motivation and arguments for building a framework to distribute 
decision support technologies. Chapter III examines the environment of the DDSN and 
identifies the roles and responsibilities of entities of the DDSN environment. Chapter IV 
examines the functions of the DDSS, identifies an architectural framework for the DDSN, 
and proposes an initial infrastructure for the DDSN. Both appendices of the thesis support 
Chapter IV. Appendix A discusses enabling technologies. Appendix B illustrates the IDEF 
0 model developed to investigate the activities and the interaction of activities within the 
DDSS. Chapter V discusses the objectives of models and simulations within DoD and how 
the DoD can exploit the DDSN technology. Chapter VI is the thesis conclusion and suggest 


areas that require further research. 











II. WHY BUILD A DISTRIBUTED DECISION SUPPORT NETWORK? 


A. INTRODUCTION 

Research in the decision sciences has resulted in the development of modeling and 
decision support applications that are useful in solving a variety of problems faced by 
individuals and organizations. (Davis, 1988) Decision Support Systems (DSS) aim to 
provide support for semi-structured and unstructured decisions in all stages of the decision 
process. DSS requires a unique interface between the user and internal databases, external 
databases, and analytical models. The dawn of the information age has brought greater 
demand for computer assistance in decision making due to the abundance of information, 
the ease with which it is obtained, and the time sensitive nature in which decisions are made. 

Enabling technologies (client server applications, object oriented design, work flow 
management tools) have reduced uncertainty in decision making by making data more 
readily available to decision makers at all levels of the organization. However, many 
decision makers are overwhelmed by the amount of new data and delay making a decision 
until the data can be understood. Furthermore, these technologies have also introduced 
complex interdependicies between the organizational structure and the information system. 
(Walton, 1989) These interdependicies have changed the organizational structure, which 
has redefined who makes the decisions within the organization. To adequately support the 
decision making process of today’s organization, a variety of decision support applications 
need to be available to all users of the organization on demand. In addition toa suite of 
tools for known re-occurring decisions, organizations will require access to a repository of 
decision support technologies for unexpected and dynamic events introduced by the 
environment. This new paradigm suggests that the decision sciences should exploit these 
enabling technologies in the development, interface, and distribution of decision tech- 
nologies. 

The underlying idea of a DDSN is to create an electronic market for decision support 


applications. This market would allow decision support and modeling systems to be 





delivered as a service rather than as a product. (Bhargava, et al., 1995) By distributing 
these technologies as services, it is believed five categories of resources that are traditionally 
used in modeling and decision making (data, models, simulations, solvers, and decision 
support packages) can be made available to all users of the network. This market will allow 
a multitude of users access to a diverse library of tools. Potential users of this service include 
research activities, academia (professors and students), military organizations, industry, as 
well as casual users who occasionally need problem solving or assistance in making a 
decision. 

This chapter examines the ideas behind developing a DDSN and the benefits of 


distributing decision technologies as a service over a global network, such as the Internet. 


B. ELECTRONIC COMMERCE 

The emergence of the National Information Infrastructure (NII) and the development 
of Internet applications such as the WWW have brought much attention to electronic 
commerce. The ultimate goal of the NII in Electronic Commerce is the creation of a 
national electronic marketplace which is secure, open, affordable, easy to access, and easy 
to use. (Gebase et al., 1993) 

1. Commercial Business and the WWW 

Today, while surfing the WWW, you can order a pizza from Pizza Hut, visit the 
archives of the Library of Congress, read the San Jose Mercury News, view video clips, 
listen to music, and go shopping in the Internet Mall. There is no other medium that is 
accessible to such variety of services and on-line functionality. The WWW and the Internet 
have demonstrated a great commercial opportunity. Commercial business on the Internet 
is expanding expeditiously, even with moderate security in place. The commercial domain 
is the fastest growing Internet group, with more than 1,500 new companies connecting to the 
Internet each month. The commercial sector now makes up more than one-half of all domain 
names according to Internet Society figures. (Ellsworth, 1995) Figure 1 illustrates the large 
growth of the Internet and the WWW. 
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Figure 1. WWW Growth on the Internet 


2 Electronic Data Interchange (EDI) 

EDI is presently being used by many individuals and organizations to automate 
simple business decisions and financial transactions. These transactions have evolved to 
reduce paperwork and to increase the speed and availability of decision making information 
for business and government transactions. An advanced NII for Electronic Commerce will 
be able to support activities such as electronic funds transfer, government regulatory data 
interchanges, enterprise integration, and computer-supported collaborative work. (DoD, 
1993) (Gebase, et al., 1995) The NII provides the enabling technologies for an electronic 
market of decision technologies. It would allow for decision technologies to be made 
available to users via a virtual repository. This repository of decision technologies will allow 
users to access and use decision technologies in conjunction with organizational data as well 
as external data sources. Potential users of this service include research activities, academia 
(professors and students), military organizations, industry, as well as casual users who 


occasionally need problem solving or assistance in making a decision. 








C. ARGUMENTS FOR DISTRIBUTING DECISION SUPPORT TECH- 
NOLOGIES 


The Internet and associated NIDR tools have streamlined the transfer of electronic 
data, which includes executable software applications. (Abernathy, 1995) (Krol, 1994) 
Presently, a variety of public domain executable applications may be downloaded from sites 
around the world. However, this approach places additional requirements on both the 
developer and the user of the application. The developer must port the application for 
different platforms and the user must have the knowledge to install, configure, and maintain 
the application on his computer. The same holds true for decision technologies; a model or 
algorithm can not be processed in real time by a solver which does not exist on the clients 
machine. 

The remote execution of these applications can be done by a procedure call through 
a Common Gateway Interface (CGI) which is used by the HTTP servers of the WWW. CGI 
allows for a simple user interface, making the execution of NIDR applications transparent 
to the user. The infrastructure of the DDSN and the providers decision technology can thus 
absorb a majority of task usually associated with the user. There are four main arguments 
for building such an infrastructure: market potential, version management, the use vs. own, 
and the interoperability or shareability argument. 

1. The Market Potential Argument 

By definition, there are limited--niche--markets for specific decision support 
applications/tools; the more specific a system is, the smaller its potential base of users. The 
lack of a large enough market for various decision technologies may often inhibit their 
development and availability. Many types of models are developed for ad hoc decisions for 
a specific organization, used once, put on the shelf, not maintained, and never used again. 
By providing technologies through a repository, such models would be available to a diverse 
set of users; expanding the market for such a model. The cost of reaching this market would 
be a fraction of the costs associated with conventional distribution channels. Users would 
be able to learn about and access a large number of decision technologies without obtaining 


the maintenance cost associated with the purchase and/or development of these applications. 


They could browse freely, a yellow pages of technologies, identifying applications that 
would be beneficial in their decision making process. 

2. The Version Management Argument 

This argument is analogous with a client server application. For example, an 
organization buys a client server word processing application. The application is installed 
and maintained by the system administrator on one computer (application server). Users of 
the network use the application as if it were installed on their terminal. When a new version 
is installed or a bug is fixed in an application, the administrator updates the software at the 
server, the change is made transparent to all users. The cost and time required to implement 
the change decreases proportionally by the number of users of the application. The version 
management argument for a DDSN is that an electronic network would eliminate, or 
minimize, many of the costs and problems associated with updating software technologies 
when many copies and many versions of the same technology are physically distributed. 
Providers would not have to create and distribute multiple copies of a product since the 
application would be running at the providers computer. Updates and new releases would 
be made available simply by setting them up for execution and listing them in the DDSN 
database. All transactions would be done electronically, eliminating the need to package, 
bill, and mail via traditional methods. 

3. The Use vs. Own Argument 

Many potential consumers of decision technologies are unwilling to invest the time, 
money, and effort required to learn about, obtain, own, and use them, particularly when the 
decision problem is non-recurring. Further, buyers of decision technologies have to deal 
with the maintenance cost and updates required due to changes in model situation or change 
in data structures. By owning a software product the user must provide for the management 
of the product and must determine if the application is providing the added value that it was 
originally purchased for. A DDSN would allow a consumer to use a decision technology, 
when needed, and be free of the problems associated with owning and managing the 
software. This would promote a "pay" for use, vice purchasing and maintaining a copy of, 


a decision technology. The costs and time associated with learning about a decision 


9 





technology and using it as a service, would be modest compared with the costs associated 
with doing so with a conventional product. 

4. The Interoperability and Shareability Argument | 

Even within organizations that have the resources to develop decision technologies, 
a repository of functional technologies offers an opportunity to share these technologies. 
This is particularly true when the organization is geographically dispersed and/or utilize a 
variety of hardware and software platforms. The DoD CIM initiative illustrates the need to 
combine information resources to reduce development and maintenance cost of information 
systems in future years. DoD and many commercial organizations of today are restructuring 
their organizational structure and redefining their business processes. (Appleton, 1993) This 
is due to enhanced technology and the need to minimize cost. Organizations of today are 
geographically dispersed, but share the same data resources. The DDSN would maintain a 
centralized library of decision technologies, allowing for decision technologies to be globally 
shared to dispersed organizations. This would increase awareness and knowledge of these 
technologies within an organization, allowing decision makers at all levels access to tools 


registered with the DDSN, regardless of the users hardware. 


D. CONCLUSIONS 

The ability to make expedient and correct decisions in today’s computing environ- 
ment requires the decision maker to have access to current data and the correct decision aids 
to process and visulize the data. Traditional research in the development of DSS’s is being 
challenged by new technologies, reorganization of organizational structures, and redefining 
who really makes the decisions within the organization. Researchers and developers of the 
decision sciences will need to exploit these enabling technologies and re-engineer the way 
decision support applications are used, developed, and distributed to accommodate the 
modern organizational structure. A DDSN is one way in which existing technologies can 
be utilized by consumers of enterprise and global networks. This architecture will provide 
a high degree of interoperability and place minimal constraints on users' hardware and 


software environments, while allowing them to use technologies residing on many different 
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kinds of computer platforms. By creating an electronic market for decision support 
applications/tools the developers and researchers in the decision sciences can bring data, 
models, simulations, solvers, and decision support packages to the largest growing medium 
of information. This market will facilitate the advertisement as well as the use of these 


technologies; expanding the market and availability of these technologies. 
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Hil. CONCEPT OF OPERATION 


A. INTRODUCTION 

Electronic services in marketing, banking, and travel are becoming popular on the 
Internet via the WWW. These services require on-line interaction between the customer and 
the provider of the service. The provider of these services must also provide back-end 
processing to render the service to the customer. A few decision support technologies are 
also available on the WWW. An application called Waste Management Technology 
Analysis and Decision Support (WMTADS) is operated by the Department of Energy 
(DOE). A user can search DOE technologies for treating waste as well as search for specific 
industry solutions to the technological challenge of treating wastes.” (DOE, 1994) The 
back-end processing of this type of technology provides for all the interaction of all 
databases and analytical models of the providers DSS with the users provided input data. 
The Common Gateway Interface (CGI) allows for the transfer of input data to the provider, 
execution of the application, and the return of output data to the user. (NSCA, 1995) This 
allows for the distribution of the technology over a heterogeneous network using a common 
interface, but does not allow for interoperability between technologies. 

One way to achieve interoperability between decision technologies across diverse 
hosts and operating systems is through a Common Operating Environment (COE). A COE 
consist of a special software layer, such as CRONUS, or a level of architecture, and object 
standardization as in the CORBA standard. (Kral, 1995) Interoperability between registered 
technologies of the DDSN would be achieved by constructing an architecture in which agents 
would mediate the transactions between the users (consumers and providers) and between 
different technologies. (Bhargava, et al., July 1995) To better understand the requirements 
of this architecture, the entities, transactions, and requirements of all entities must first be 
identified. This chapter develops the requirements and responsibilities of the entities of the 


DDSN environment and defines the transactions between entities of the DDSN. 


2WMTADS is available at URL: http://mwir.lanl.gov/. 
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B. THE DDSN ENVIRONMENT 
The DDSN environment consist of the network, providers of decision technologies, 
consumers of decision technologies, and the Distributed Decision Support Server (DDSS) 


as illustrated in Figure 2. 





Providers 


Figure 2. DDSN Environment 


1. The Network 

Allows for the physical transfer of data and the seamless interaction between different 
types of platforms. All entities of the environment are assumed to have access to the 
network. It is believed that different types of networks could facilitate the distribution of 
decision technologies, however, in this thesis the network discussed refers to the Internet. 

2. Providers 

Organizations, developers and/or individuals who desire their decision technology 
to be executable over the network, are considered providers. The provider is ultimately 
responsible for the functionality and dependability of the hardware and software for which 
the application runs. The provider must be able to define the structure for inputs and outputs 
of data required by the application. The provider is also responsible for the security of all 
input data from the consumer and the results produced from the application. At this time, 


two categories of providers exist, “Independent” applications and “Exclusive” applications. 
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a. “Independent” Applications 

Providers that have provided a CGI for their applications which allow for the 
transfer of data and the execution of their application need only to register as a provider of 
the decision technology and register the application with the DDSS. The application can 
execute independently of the DDSS. The Uniform Resource Locator (URL) is used to 
interface the technology with the consumers of the DDSN. 

b. “Exclusive” Applications 

These providers must also register as a provider of the decision technology 
and register the decision technology itself. From the metadata obtained during registration, 
a series of HTML documents and CGI scripts will be developed by the DDSS to provide the 
needed interface between an HTTP server and the providers application (Bhargava et al, 
Germany June 95). Such applications executes exclusively in the DDSS environment. 
These interfaces will be technology dependent and will be constrained by the server support 
of the provider. 

The provider is also responsible for maintaining a WWW browser application 
that supports the use of HTML forms; this is required for on-line registration of the provider 
as well as the technology. Depending on the type of application, the provider must also 
provide various servers (SMTP, FTP, Gopher, etc.) to allow for the transfer of input data as 
well as the return of output data to the consumer. 

3. Consumers 

A consumer of the DDSN is any person or organization who is in the market for 
computational decision support services and registers with the DDSS. The consumer is the 
end user of a decision technology which has been made available by a provider. A consumer 
is responsible for maintaining a WWW browser application that supports the use of HTML 
forms and NIDR tools to support the transfer of data as required. Consumers are responsible 


for the decisions made from the use of applications provided via the DDSN. 
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4. Distributed Decision Support Server (DDSS) 

The DDSS provides the mechanisms which allow users to register, search for, 
connect to, and execute a decision technology. The DDSS is comprised of hardware, soft- 
ware, and the personnel assets which allows for the functionality of the network. It’s purpose 


is to provide mechanisms for: 


® On-line registration. 

© Validation and verification of users and technologies. 

@ Help desk service. 

® Creation of a common interface for exclusive technologies. 
e Yellow pages of executable decision technologies. 

6 Translation of data structures to achieve interoperability. 


® Support functions. 


C. DDSN TRANSACTIONS 

Transactions are initiated by the users of the DDSN using forms capable WWW 
browser (Netscape or Mosaic) and are mediated by agents of the DDSS. There are five 
categories of transactions within the DDSN environment: registration, log-in, connectivity 
to a decision technology, execution of a technology, and standard support functions (all other 
transactions required to support the first four categories of transactions). 

1. Registration 

All users of the network are required to register with the DDSS. This is done on-line 
via HTML forms or off line by E-mail. Registration is required to establish access via login 
and password to the services of the DDSS. Registration information is also used in the 
management functions required of the DDSS (billing, user reports, etc.). Providers must also 
register their decision technologies. The metadata information obtained during registration 
is used by the DDSS to verify, validate, accredidate, and construct a common interface as 
required. A validation message acknowledging the successful registration of a user or the 


state of a technology registration is sent to the provider by the DDSS via E-mail. 
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2. Logging In 


Once a user is registered he simply logs into the system using the login and password 
established at registration. Once logged in the user can activate different agents within the 
DDSS to obtain the functionality (search, browse, edit registration information, use a 
technology) desired. 

3. Connectivity to an Application 

Once a technology is selected for use, the user initiates a request via a hypertext link 
or GUI to the DDSS to use said technology. Due to the stateless state of the HTTP the user 
is connected directly to the providers or warehouse server at this time. The user can read and 
learn more about the application and will then be asked to submit data and invoke execution 
of the application. 

4. Execution 

a. Input Data Transfer 

Since the DDSS mediates all transactions, the data is sent via the DDSS, 
translation occurs, and the data is forwarded to the providers site. Ifthe application is an 
independent technology, a translation process is not required, therefore, the input data is sent 
directly to the provider. 

b. Invoking Execution 

Once the data is made available to the provider, the application is invoked by 
either the consumer or the DDSS. Again this is dependent on the type of application. Use 
of an exclusive or invoking multiple applications would require the DDSS to monitor the 
state of each process and invoke execution once the processed data is received by the next 
application. An independent technology such as a WMTADS is invoked directly by the 
consumer as there is no need for translation of the output data for input to another 
application. 

Cc. Receipt of Output Data 

Once the application completes processing, the output data is sent back to the 
user and the DDSS. If it is a single transaction, the transaction is complete upon receipt of 


the output data. The consumer can then use the technology again or use another application. 
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For multiple application processes the output data is converted by agents at the DDSS and 
made available as inputs to the next application. Once the data is available at the next site 
the DDSS invokes execution of the application. This continues until the process is complete. 
The user will receive output data from each application used. 
5. Standard Support 
These transactions may be directly or indirectly initiated by the user. This support 
can be broken into two categories; help desk and management. 
a. Help desk 
Most of the functions of the DDSN are automated, however, a need exists for 
a mechanism to allow interaction between users and the DDSS staff. Initially, a help desk 
between users and the DDSS staff is envisioned using standard collaboration tools. These 
tools include E-mail, list serves, news groups, and PC video conference. A consumer can 
get help on the use of a decision technology and a provider can get assistance in registering 
a new technology. 
b. Management 
These transactions are those that are indirectly initiated by the users by simply 
using the network. This transactions consist of: user verification messages, technology 
usage reports, general management reports (consumers, providers, technologies available), 


and billing summaries. 


D. CONCLUSIONS 

This chapter is informative in nature and gives the reader a comprehension of the 
functions of the overall system. By identifying the roles and responsibilities of all entities 
and the transactions required between those entities, it is evident that the architecture and 
infrastructure of the DDSS is a determinant factor. The DDSS architecture will replace the 
software layer and the requirement for standardized data objects as used in the COE. It is 
believed that this will provide consumers with greater availability and flexibility in using 


technologies and external data sets in problem solving and decision support. Defining the 
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DDSN architecture is crucial in developing the mechanisms of the DDSS and is the focus 


of further research. 
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IV. DDSN ARCHITECTURAL OVERVIEW 


A. INTRODUCTION 
The term architecture and infrastructure are used diversely and interchangeably by 


professionals of information technology. Webster dictionary defines these terms as: 


Architecture: The design or structure of something. 


Infrastructure: The basic framework of a system or organization; fundamental 
facilities, as transportation and communication systems. 


For the purpose of this thesis the following definitions are provided: 


Architecture - The structure of components in a system, their interrelationships, 
and principles and guidelines governing their design and 
development over time. 


Infrastructure - Resources (personnel, hardware, software, communications) used 
to achieve desired functionalities of a system. 
This chapter presents an overview of the DDSN architecture and discusses DDSN 


infrastructure requirements by examining the requirements of each entity. 


B. DEFINING THE DDSN ARCHITECTURE 

The main objective of the DDSN architecture is to provide a truly heterogeneous 
system to users with minimal standards and conventions mandated. The architecture will 
allow users freedom of choice in use of a browser to access the DDSN and will not require 
compliance of standards and conventions in the development of decision technologies. The 
architecture will additionally allow for interoperability between applications by using 
translation mechanisms vice traditional COE technology. The initial DDSN architecture is 
based on common interface standards presently used by the WWW, additional components 
will be added at different stages of development to introduce new functionality. The initial 


architecture framework of the DDSN is defined by: defining the development stages of the 











DDSN, reviewing objectives of the system, addressing technical considerations in achieving 
the system objectives, illustrating a reference architecture, and identifying required standards. 
1. DDSN Development Stages 
The development of the DDSN will be done in progressive stages due to different 

levels of complexity in functionality, evolving technologies, and some unresolved issues. 
Each development stage will allow more functionality to the users of the DDSN. Six levels 
of development are identified below: (Bhargava, et al., February 1995) 

a. Level 0: A Repository of Available Decision Technologies 

This is nothing more than a searchable electronic library of technologies in 
which the user can search for and learn about a decision technology. 

b. Level IA: A Repository of Executable Decision Technologies 

This level introduces invoking execution of the technology by the consumer. 
After searching for an appropriate technology to solve a specific problem, the consumer can 
select one for use. The consumer can transfer data, invoke execution, and receive an output 
from the application, all of this by using a WWW browser. 

C. Level 1B: Automating Setup of Decision Technologies 

Level 1B automates the creation of the provider’s interface. This is a software 
module which will automatically generate the scripts and files required from the metadata, 
provided during registration. 

d. Level 2A: Using Multiple Applications to Solve Problems 

This level will allow interoperability between technologies. The user initiates 
sequencing of technologies and transfer of data, but the DDSS will do the translation of data 
types. 

é. Level 2B: User Defined Multiple Use of Technologies 

The consumer initiates usage of a sequence of technologies to be used and 
transfers the initial data to the DDSS. The DDSS will have the knowledge about the 
technologies and where they exist to translate the data set and transfer it to the first 
technology. Upon completion, the output of the first technology is sent back to the DDSS, 


translation occurs and the data is sent to the next technology. This process continues until 
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the end of the sequence. The consumer receives an output from each technology used in the 
process, allowing the consumer to monitor progress. 

Sf Level 3: Use of Intelligent Agents to Select Technology for Use 

The final level of development provides intelligent problem solving by using 
intelligent agents to choose the best technology alternative. The consumer would simply 
state the problem, the DDSS, using an intelligent search agent would then find the best 
technology or sequence of technologies to solve the given problem. The consumer would 
need only to transfer data, initiate execution, and receive output data. 

zi Architecture Objectives of the DDSN 
Chapter III of this thesis identified the transactions required within the DDSN. From 

those transactions we identify the following architecture objectives are identified. 

a. Transparency 

Network navigation, transfer of data, security of information, input formats, 
data storage, and search mechanism will be internal functionalities of the DDSS. This will 
create a seamless, transparent interface for the completion of these functions. The interface 
needs to be simplistic to fit the diverse user group of the DDSN. 

b. Interoperability 

The decision technologies accredited for use on the DDSN will allow for 
heterogeneous use. Additionally, the DDSS will allow interaction between applications to 
support sequencing of multiple technologies for problems that require multiple applications. 

Cc. Uniformity 

The user will see the same interface no matter what computer platform is 
used. 

d. Flexibility/Extensibility 

New technologies can be added to the network without any effect on existing 
technologies. From the users perspective, the network will provide a variety of technologies, 


used by a diverse set of users in changing environments. 
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é. Distributed Environment 
Users, providers, and technologies will be geographically dispersed and 
connected by an electronic virtual heterogeneous network. This will allow for limited 
resource requirements to obtain decision support services any time, any place. 
a Technical Considerations 
The idea behind a DDSN is based on new and evolving technologies and the 
development of software agents as translation mechanisms instead of a COE. Technical 
considerations will heavily influence the DDSN architecture and infrastructure. The DDSN 
architecture must allow for these future technologies and concepts to evolve. 
a. Enabling Technologies 
Appendix A identifies the enabling technologies that the author feels will be 
essential in the successful development of a DDSN. 
b. Unique DDSN Software Development 
The software agents and middleware which will provide for automatic regis- 
tration and interoperability between applications are a critical success factor in the proof of 
concept and of the development of the DDSN. Requirements are presently being identified 
and options are being researched. (Bhargava, et al., July 1995) 
4. Architectural Framework 
The entities of the DDSN environment were previously introduced and require no 
further explanation. Figure 3 is introduced to illustrate a reference architecture of the DDSN. 
This architecture can be described as a conglomerate of provider nodes which allow their 
decision technologies to be accessed and used by a variety of consumer nodes interlinked and 
controlled by the DDSS node via a global network. 
J DDSN Standards and Conventions 
A major goal of the DDSN idea 1s to increase availability of decision technologies 
to users of a global network. COE’s require a suite of common tools on all users’ machines. 
The DDSN idea would allow consumers to use browser applications of their choice; 


providers can build applications using proprietary software and run the application on the 
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Figure 3. DDSN Reference Architecture 


computer platform of their choice. We believe that the standards and conventions can be 
limited to the defacto standards used today by the Internet and WWW. To obtain minimal 
functionality, all users must initially have: connection to a network, a TCP/IP stack installed, 
a form’s capable browser, and complete the registration process as a consumer or provider. 

a. Layered Reference Model 

An architecture from the perspective of a reference model is shown in Figure 
4. This model was developed to identify standard services of the DDSN and to provide an 
elementary view of the DDSN for future discussions. The reference model is divided into 
four functional layers: the physical layer, transport layer, DDSN service layer, and the 


application layer. 
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Figure 4. DDSN Reference Model 


(I) Physical Layer. Consists of the communication lines required 
to connect to the network. This will be the choice of the consumer and provider and will 
vary according to availability of services. 

(2) Transport Layer. Communication software which allows for 
communication functionality. Commonly called TCP/IP stack or DoD protocol stack. 

(3) DDSN Service Layer. This layer contains users defined client 
software which allows access to the DDSS. The user chooses this software, but must 
conform to specific standards of the DDSS. An example would be a WWW browser. A user 
can use the browser of his choice if it is HTML 2.0 acquiescent. 

(4) Application Layer. This layer contains all exclusive and 


independent decision technologies previously registered and available for use on the DDSN. 
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b. Functional Standards 

DDSN functionality is currently based on the technical services available on 
the WWW. Table 1 identifies the recommended or de-facto standards for each of the 
technical services to achieve the following functions of the DDSS. 

(1) User Registration. The user establishes an account with the 
network by providing pertinent information about their self or the technology they are 
registering. 

(2) Discovery and Search. A mechanism to search for and learn 
about a decision technology. 

(3) Data Transfer. The transparent transfer of data between 
consumer and provider, provider and user, and technology and technology. 

(4) Execution of Applications. This function invokes execution 
of an application. 

(5) Support Functions. All additional functions required to 
support users of the network. These functions would include such things as: On-line help 


services, reports, validation messages, and all management functions. 


C; DDSN INFRASTRUCTURE 

The DDSN infrastructure is comprised really of three separate infrastructures 
(consumers, providers, DDSS) which a fourth infrastructure (communication) unites. The 
absence of any one of these infrastructures will desolate the DDSN concept. In developing 
the DDSN infrastructure, discussing connectivity, hardware, software, and personnel 
requirements introduces the requirements of each infrastructure in general terms. A specific 
infrastructure will depend on the stage of development, established performance measures, 


amount of usage, types of data transfers, and known interdependicies between specific 


resources. More emphasis is placed on the DDSS infrastructure as it is the main entity of the 
DDSN. 
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1. DDSN Communication Network Infrastructure 
A network infrastructure capable of dealing with the amount and type of data 
envisioned to seamlessly integrate all simulation and modeling technologies does not 
currently exist. The Defense Simulation Internet (DSI) program is accelerating commercial 
development of the technologies needed by the simulation community for distributed work 
environments. “The ultimate goal is deployment of a gigabit network that will be inter- 
operable with commercial, optical and secure wireless networks.” (ARPA, 1995) Use of the 
DSI or a comparable network is required to use the DDSN as a global network. 
ya Consumer Infrastructure 
Three areas of concern for the consumer’s infrastructure exist: access to the network, 
computer platform, and required software. 
a. Network Access 
The type and speed of a network access are dependent on each consumer’s 
individual requirement. ISDN and ATM technology are presently increasing the bandwidth 
availability to the end user. Internet dial-in connections are presently available at 14.4 or 
28.8 Kbps. Consumers with ISDN presently connect to the Internet at 56 or 128 Kbps. It 
is projected that by the year 2004, Internet providers will provide T1 carriers to the home for 
about the same price of a modem connection today. (Robinson, 1995) 
b. Hardware 
An independent variable to the DDSN. Hardware used is dependent on the 
user requirements. 
ra Software 
The only required software is TCP/IP stack software and a WWW browser 
client which combine to make a common user interface. The consumer has choice in which 
TCP/IP stack and WWW browsers they choose to use. Additional TCP/IP software applica- 
tions such as an E-mail client and FTP client are useful to the user. These applications are 


again the choice of the end user. 
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3. Provider Infrastructure 

The provider has the same requirements for network access, but has additional 
requirements in hardware, software, and personnel. A service provider must provide an 
infrastructure which provides a service to consumers which are useful, reliable, and secure. 

a. Hardware and Software 

Providers of decision technologies will have freedom of choice in the 
hardware and software required to provide the processing of the decision technology and the 
transfer mechanism to support the transfer of input and output data. The type of technology 
and the interface requirements of the application will drive the software and hardware 
requirements for the provider. 

Hardware and software requirements will be much less for independent 
providers since the provider’s HTTP server can accomplish the transfer of data. The 
provider must provide the hardware and software to run an HTTP server and the decision 
technology application. CGI scripts accomplish the interface between the HTTP server and 
the decision technology back end process. Additional support functions such as: secure 
storage and transfer of data by files, and transferring output data back to the consumer will 
require additional server software and will be dependent on the provider’s interface require- 
ments. These additional requirements are independent to the DDSN and are dependent on 
the provider’s preferences in providing the service. 

b. Personnel 

The provider is responsible for the functioning of the information system 
which provides the decision technology. Programmers, technicians, support personnel are 
the responsibilities of the provider. 

4. DDSS Infrastructure 
A Structured Analysis and Design Technique (SADT) model better known as an 
IDEF 0 model was developed to understand the activities and interaction of activities of the 


DDSS better. Appendix B illustrates the IDEFO model of the DDSS activity “Provide 
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Decision Support Technologies.” A functional prototype DDSS, named “DecisionNet’” was 
developed to compare and contrast different design options and to gain understanding of the 
total DDSS concept. (King, 1995) 

a. DDSS Connectivity 

The DDSS entry gateway needs to have a direct connection to the global 
communication network. A high volume of data is sent to and from the DDSS by the 
consumers and the decision technologies. A large pipe will be required to provide reasonable 
response time to the consumers. 

b. DDSS Information System 

The DDSS can be viewed as a business process consisting of an information 
system consisting of a variety of hardware, software, and personnel which will provide all 
required functionalities to users of the DDSN. Therefore, the activities and interaction of 
activities within the DDSS will heavily influence the DDSS infrastructure. Modeling of the 
DDSS identified three main activities, which will prominently influence the infrastructure 
of the DDSS: registration of users, validation of technologies, and providing an interface 
for the technology. 

(I)  DDSS Hardware. The current DDSS prototype uses a 

Macintosh P7100 as an entry HTTP server which we have tasked with serving DDSN 
introductory information and maintaining user statistics. A UNIX SPARC 2 is called to do 
all login functions, forms processing, search mechanisms, E-mail functions and all other 
back end processing. This configuration demonstrates that a distributed server configuration 
using a variety of hardware could support the DDSS. However, this is probably an 
impractical solution due to hardware and software maintenance issues. A UNIX-BASED 
commerce server (SPARC 20) with all server software installed will be sufficient as an initial 
gateway server. All back end processing will be supported via additional platforms as 


required. The determining factors in selecting the hardware configuration will be based on: 


*TecisionNet” is a WWW based functional prototype, which allows access to a 
distributed network of modeling and decision support systems over the Internet. 
DecisionNet” is available for use at URL: http://dNet.as.nps.navy.mil/dNethome.html. 
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performance measures, required processing speeds, number of simultaneous users, security 
requirements, level of distributed computing environment, ease of maintainability, and cost 
of service and support. | 

(2)  DDSS Software. Universities have built and distributed most 
of the server software used in the development of the prototype as free unsupported freeware. 
The software is not of production quality and is consistently receiving configuration 
upgrades. Freeware is appropriate in establishing proof of concept, but the DDSS will 
require an established and supported server software package. The following server applica- 
tions are required at this time: DNS, FTP, HTTP, SMTP, Telnet. Additional Software 
applications such as NNTP, MMITP, ListServe, DBMS, DDSS middleware will be required 
to support back end processes and support functions of the DDSS. 

(3) | DDSS Personnel. The personnel required to support the DDSS 
will be largely dependent on the technical staff required to support the information system. 
Network managers and system analysts will be required to maintain a 24-hour information 
system. Additional personnel classified as “Decision Support Specialist” are tasked with 
classifying, validation, and verification of technologies registered with the DDSS and later 
as help desk consultants. Programmers will be needed to develop technology specific 
interfaces and middle-ware required for automated technology registration and data 
translations. Personnel required to support the DDSS should decrease as functions are 
automated and different stages of development are realized. Additional help desk personnel 
will be required to help in setup, execution, and monitoring use of applications during the 


middle stages of development. 


D. SUMMARY 

The DDSN architecture is a very high level architecture which will continue to evolve 
over the project development stages. This architecture is based on the present architecture 
of the WWW, which being in an infancy state is also evolving. Further research, enabling 
technologies, and development of the DDSS will influence the architecture of the DDSN. 
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It is evident from the initial architecture that further research and development will 
be centered around the DDSS architecture and infrastructure. However, we must also 
establish a market for distributed decision support technologies. We must identify enter- 
prises and functional areas that need this type of technology and obtain their requirements. 
Consumers’ willingness to divulge corporate or personal data to a distant site for processing 
must be analyzed. These type of issues concerning the providers and consumers also should 
be considered research challenges. Without providers and consumers, a DDSN does not 
exist. 

This chapter provides an initial architecture framework that documents the ideas 
behind the DDSN concept. It establishes a road map which researchers and developers can 
follow to continue research and development of the DDSN ideas. Since the DDSN concept 
was developed in an academic environment the initial architecture is based on ideas of the 
initial project team and does not reflect requirements established by a single customer 


requiring this service. 
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V. MODELING AND SIMULATION IN THE DOD 


A. INTRODUCTION 

Reductions in force structure and annual operating expenses have placed more 
emphasis on the use of models and simulations to maximize use of available resources. DoD 
believes that Modeling and Simulation (M&S) can improve military capability and decision 
making in four areas: readiness, modernization, force structure, and sustainability. The DoD 
M&S vision is to support DoD components in a variety of functional areas by developing, 
maintaining, and distributing a wide range of models and simulations to support their 
objectives. Figure 5 illustrates the range of the vision for M&S in the DoD. (DoD, 1994) 
(DoD, 1995) 
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Figure 5. Range of M&S in DoD, DoD Master Plan, DoD 5000.59Paa 


The Defense Modeling and Simulation Office (DMSO) was established to coordinate policy, 


establish interoperability standards and protocols, promote simulation in the military 
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services, and to establish guidelines for coordinating simulation, war gaming, and training. 
(U.S. Senate, 1990) The DOD Executive Council for Modeling and Simulations (EXCIMS) 
was established to provide the Under Secretary of Defense (Acquisition & Technology) 
(USD (A&T)) a mechanism to establish and implement DoD policy, initiatives, standards, 
and capabilities to enhance (M&S) in the DoD. EXCIMS is comprised of DoD Component 
representatives and is chaired by the Director, Defense Research and Engineering (DDR&E). 
(DoD, 1994) DoD has the management resources in place and must now bring their vision 
to reality. 

This chapter discusses objectives of the DoD M&S Master Plan that are relevant to 
the concepts of the DDSN, identifies ongoing DoD M&S and C4I projects that are similar 
and/or related to the DDSN concept, and discusses how the DDSN concept could be used to 
support DoD functional areas with decision support technologies. 


B. DOD M&S MASTER PLAN OBJECTIVES 

The DoD M&S Master Plan establishes long term objectives for M&S within the 
DoD. (DoD, 1995) The plan is broken down into six objective areas as illustrated in Figure 
6. Objective one, five, and six of the master plan parallel the concept of the DDSN. DoD’s 
emphasis 1s on the use of simulations for decision support, while the DDSN emphasis is on 
analytical models. The common objectives are discussed below. 

1. Common Technical Framework for Modeling and Simulation 

DoD desires a common framework which will facilitate interoperability between 
models and simulations, integration of M&S with C4I systems, and increased usage and 
reuse of M&S. Their approach 1s to dictate a high level architecture and to standardize 
representations of data with which all DoD models and simulations will conform. While the 
methodology to obtain the objective is different, the goals are similar to that of the DDSN. 
The DDSN concept establishes a multi-dimensional taxonomy of objects which are based 
on the inputs and outputs of the application. The provider declares input and output data 


formats in a “Parameterized” Format Description Language (PFDL) and is translated by 
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Figure 6. DoD Modeling and Simulation Objectives; DoD Master Plan DOD 
5000.59Paa 


agents of the DDSS. Format conversions are done as required to allow for transfer of user 
data and interoperability between applications. 
2. Establish a M&S Infrastructure to Meet Developer and User Needs 
Goals of the DoD M&sSS infrastructure are also similar to that of the DDSN. The DoD 
infrastructure is broken into five components defined as the following sub-objectives: 
a. Field M&S Systems in Adequate Numbers to Meet End User Needs 
A DoD Inspectors General (IG) inspection conducted in March of 1993 
substantiated that the DoD lacked the ability to effectively and efficiently use models and 
simulations. One of the major findings was that applications were developed as stand alone 
models with no reuse capability; another was that there were redundant investments in 
similar systems. An estimated 800 million dollars could have been saved in FY93 if an 


effort to consolidate systems would have occurred. (Mercer, et al., 1994) 
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In an effort to reduce redundancy, DoD plans to identify user requirements 
for M&S within five functional areas: Education, Training, and Military Operations 
(ETMO), Analysis, Research and Development (R&D), Test and Evaluation (T&E), Projects 
and Logistics (P&L). Once user requirements are identified, DoD will plan and program the 
fielding and interconnection of the necessary models and simulations to support the needs 
of the entire DoD. Unused M&S systems will then be phased out of the system. 

Identifying requirements for a single user is a difficult task, identifying 
requirements of multiple users over five different functional areas seems impossible. It could 
be argued that this is an unrealistic objective due to continually changing requirements. The 
DDSN concept takes somewhat of a reversed position on achieving this objective. Instead 
of reducing the applications available, all M&S resources would be made available, giving 
the user more flexibility in choosing and using the tools to support the mission. 

b. Validation, Verification, and Accreditation (VV&A) 

DoD realizes that VV&A and Verification, Validation, and Certification 
(VV&C) is required to achieve confidence in the use of M&S by the user community. 
Standards, policies, and procedures need to be developed to achieve VV&A and VV&C. 
The DDSN concept shares the same concern for VV&A of technologies made available on 
the DDSN. VV&A is initially the responsibility of the provider of the technology, however 
the DDSN will need a process to verify the providers VV&A. 

C. Repositories 

To enhance development, use, and increase awareness of models and simula- 
tions, DoD is developing a resource library. An Interim M&S Resource Library IMSRR) 
is presently operational with a WWW interface at Fort Huachuca.’ The goal of this library 
is to provide developers and users of M&S with “timely, verified, and validated data, 
metadata, algorithms, models, simulations, and tools.” This repository allows users to learn 


about a technology by reviewing background information (e.g., data source, VV&A/C 


*Available at URL: http://huachuca-jdbe.army.mil; hosted by Joint Data Base 
Elements for Modeling & Simulation (JDBE). 
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history, algorithms used, developer). The user can then decide if the technology is useful and 
can retrieve the technology for use. This type of library may support a developer, but will 
probably not be used by an average user of M&S. The arguments for developing a DDSN 
established in Chapter II support this position. An average user wants to use a technology 
and does not want to worry about the configuration and management of it. 

The DDSN repository is similar, but is described as an executable electronic 
library of decision technologies. The DDSN repository could be used as both a reuse and 
use library. This would benefit both the developer and the user of M&S. The developer 
could review the background material and also execute the technology to determine if the 
functionality of the technology met the requirements. The user would access, provide data, 
and use the technology as required, without obtaining the technology software. 

Another problem with the IMSRR and other catalogs of M&S technologies 
is the storage of metadata concerning the technology. Once the information is provided, it 
is immediately outdated. In today’s distributed environment this information should be 
dynamic. When a model or simulation technology is modified, all repositories should also 
reflect that change. The IMSRR and M&S catalogs require background information be 
managed by the facilitator of the repository, not the developer of the technology. Because 
technologies are always changing and improving, the developer should be made responsible 
for this information. 

d. Communications 

DoD presently has the Defense Simulation Internet (DSI) in place and 
believes that by increasing reliability and bandwidth that DSI can be transitioned into an 
operational service for the distribution of models and simulations. The current defense 
information infrastructure, commercial services, and radio frequency communications will 
be utilized to link DSI with C4I systems. This will allow M&S support to any DoD user, 
anytime, anywhere. The DDSN has the same goal; decision support to any user, anytime, 


anywhere. The same type of communication requirements exist for the implementation of 
the DDSN. 
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é. Coordination Center 

The DoD 1s establishing a M&S Coordination Center (MSCC). This center 
will provide support to all users’ (Cincs, Services, Agencies, Project Managers) of all 
functional areas. The MSCC will be responsible for coordinating, advising, and establishing 
use of world-wide distributed simulation capabilities. Due to the size and complexity of this 
M&S network, human assistance will be required to coordinate usage, assist users, and to 
make M&S systems available. 

The DDSN also requires an organization of this type, but of a much smaller 
scale. By using software agents it is envisioned that the resources required to provide some 
of these functions can be automated. The best example of this is defined by the level three 
configuration of the DDSS. At level three the user merely states the problem and the DDSS 
would automatically identify the best technology to assist the user. 

3. Share the Benefits of M&S 

This objective within the DDSN concept is to allow a diverse set of users access to 
a variety of decision support technologies with minimal overhead. However, DoD defines 
this objective by three sub-objectives: 

a. Quantify the Impacts of M&S 

In an attempt to assess the value of M&S, DoD desires to establish quantita- 
tive measures which illustrate the utility of M&S within functional areas. While this is not 
a functional goal, it serves to justify and educate agencies that are ignorant of M&S 
capabilities. 

b. Education of M&S Users 

New users of M&S will require education and training in establishing and 
using M&S resources. DoD plans to conduct seminars and workshops to expand user aware- 
ness across the M&S community. Since the DDSN is WWW based, the training, education 
and dissemination of information is supplementary to the system. The DDSN also allows 
for a serendipity learning environment; the user may have no idea that an application exist, 
but by browsing the repository may find a suitable technology to support a known or future 


requirement. 
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C. Technology Transfer with Other Agencies 

DoD desires to stimulate technology transfer of M&S between other govern- 
ment agencies, private industry, universities, and other nations. Traditional methods such 
as demonstrations and meetings are being planned to accomplish this objective. The transfer 
of technology is also built into the DDSN. Developers can learn about and test an applica- 
tion maintained in the executable repository of the DDSS. If additional information is 


required about a technology, developers can go off line and discuss relevant issues. 


C. DOD M&S AND C4I PROJECTS 
There are a few projects presently being researched and developed within the DoD 
which demonstrates the integration of M&S with C4I. A few of these are discussed below. 


1. Distributed Interactive Simulation (DIS)/Advanced Distributed Simula- 
tion (ADS) 


Originally sponsored by Defense Advanced Research Projects Agency (DARPA) and 
known as the SIMNET (SIMulation NETwork) program, this concept has evolved into DIS, 
ADS, and now, High Level Architecture (HLA). DIS is the infrastructure which implements 
the concepts of ADS. The ADS concept is to synthetically create large environments so 
users- can interact in real-time simulations. The HLA architecture creates a framework for 
developers and policy makers to address simulation design and implementation issues. 

The initial focus of this technology has been in training, however DIS/ADS is seen 
as a tool for evaluating new concepts in a variety of military functional areas. The Defense 
Science Board (DSB) believes that this technology will also aid in research and development, 
prototyping of systems and testing of weapon systems in synthetic environments. These 
environments or virtual worlds are linked electronically to give a shared representation of 
space. Linkage to other sites allows real time interaction, with man-in-the-loop affecting the 
outcome. The two distinct characteristics of this technology are that the simulations are 
physically separated and they must be electronically connected to allow for a common 
picture of the environment space. This allows all nodes to act, interact, influence and 


respond within the same battle space. (Mercer, et al., 1994) 
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Ze Common Operational Modeling Planning and Simulation Strategy 
(COMPASS) 


The goal of COMPASS is to “bring modeling and simulation services and collabora- 
tive planning tools to C41.” A common messaging environment using middleware is used 
to extend DIS protocols from modeling and simulation to C4I systems. COMPASS provides 
an Application Program Interface (API) which acts as a presentation layer and translation 
layer between legacy planning systems. This allows for the use of proven planning systems 
to be interfaced using commercial distributed computing applications. The Distributed 
Collaborative Planning (DCP) applications (whiteboard, video conferencing, shared overlay 
management) allow planners to collaborate on plan development. The modeling and 
simulation tools allow all planners to preview composite mission and simulated mission 
rehearsals. This program leverages current investments (legacy planning systems), allows 
collaboration between geographically dispersed planners, and allows for a preview of the 
plan developed. (Nayfack, 1995) 

3. Joint Task Force/Advanced Technical Demonstration (JTF/ATD) 

The JTF is the crisis response team for the DoD and is required to respond to a 
variety of situations. The idea of the JTF/ATD is to provide the JTF Commander with the 
right tools to create plans, analyze courses of actions, communicate plans, and to enhance 
perception of the current situation. The JTF/ATD is an Advanced Research Projects Agency 
(ARPA) project which envisions “a mobile distributed network of graphic planning cells 
sharing a common reasoning infrastructure and architecture.” (Kral, 1995) This environ- 
ment would allow for concurrent assessment, plan generation, scheduling, and analysis 
processes between the Commander Joint Task Force (CJTF), CJTF components, and 
supporting Commander-in-Chiefs (CINCS). The architecture is based on a COE and shared 
object classes with flexibility in adapting to current needs by integrating new software 
modules. Flexibility is established by developing new software modules for different 
situations. A module may take between two person hours to a few person weeks to develop 


and integrate with the system. (Erman, et al., 1994) 
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D. DOD AND THE DDSN CONCEPT 

1. Overview 

As identified by the discussion of the C4I/M&S projects, it is evident that the DoD 
is moving towards a proprietary system to integrate M&S with C4I. Developing a proprie- 
tary system will allow for an efficient and reliable method to interface required M&S 
applications. A HLA must be established and maintained that developers and policy makers 
must conform to. Developers must conform to these standards and data conventions to 
guarantee interoperability and information transfer between applications. New M&S 
applications, will be developed easily as they will use standardized information definitions. 
Preferred stove pipe applications will be re-engineered or middleware will be developed to 
allow for their use in this architecture. 

The DDSN concept allows for applications to be built independent of a standardized 
architecture and allows for transfer of information by allowing middleware to translate the 
input and output data. While it can be argued that the translation of middleware is 
maintenance intensive and promotes building of stove pipe applications, new technology is 
envisioned that will dispute this argument. Software agents are becoming popular in 
automating processes that usually require extensive interface and communication. By 
developing these software agents to automatically register independent technologies and 
build required interfaces, the maintenance of such applications should be reduced. 

pa DDSN Areas of Use in the DoD 

It is the authors opinion that the DDSN is not a concept that would replace a 
proprietary DoD M&S distributed system, but one that would support or complement it. The 
proprietary system should allow a method to access and use other M&S resources to assist 
in the decision making process in the event a tool or data is not available. Under the DDSN 
concept, a large repository of decision technologies from universities, research institutions, 
industry, and individuals would be made available to the DoD for use as required. Military 
schools, military analyst, acquisition professionals, and individuals could all benefit by 
having access to a repository of such technologies. A discussion on how these areas could 


benefit from the DDSN concept is provided. 
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a. Military Schools 

Students at graduate, mid-level, and upper level schools could share tech- 
nologies that were developed by students of other schools and curriculums. A lot of time is 
wasted developing models and algorithms which have previously been developed to support 
another students or professors work. A DDSN would increase awareness and use of existing 
technologies from all Colleges and Universities abroad. These technologies could also serve 
as starting points for re-engineering or development of new applications. 

b. Acquisition Professionals 

The use of Models and Simulations within the acquisition process presently 
supports all communities involved in the development, design, manufacturing, and testing 
of the system being acquired. A variety of models, simulations and supporting data is 
required to conduct mission area assessments, mission needs analysis, cost and operational 
effectiveness, measures of effectiveness, and measures of performance. The list of analysis 
tools available to support a program manager is quite extensive. The data sets, models and 
analytical tools required by all acquisition activities could be provided for use in a distri- 
buted environment as outlined by the DDSN architecture. All activities could share the same 
supporting data and analytical tools from the requirements to the implementation stages of 
the project life cycle. If supporting data was changed, it would only have to be changed at 
one location, reducing the chance of errors in analysis. This would also promote reuse by 
making applications available for future projects. 

~~ Military Analyst 

The complexity of the modern battlefield and the amount of information 
available to the military commander has increased reliance on supporting staff and military 
analyst. Analytical support is being provided to field commanders by establishing help desk 
or anchor desk in specific functional areas (e.g., logistics, intelligence, meteorology, 
manpower). These help desk are located in the rear areas and are manned by professional 
analyst and contain analytical tools to support the commanders decision making process. 


High speed communications are used to transmit unique data and request for analytical 
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support from the commander, the analyst will then use a variety of tools to compare contrast 
and give feedback on the request. 

Today’s military performs a variety of missions which are categorized as 
“Operations Other Than War.” Commanders are often confronted with scenarios that current 
military doctrine and tactics do not address. Analytical tools and information unique to these 
new missions may also not be available. The DDSN concept would allow analyst in a 
variety of disciplines to connect to a repository of decision technologies outside of DoD that 
may support these operations. In addition to the predefined tools that have been established 
to support established doctrine and tactics, a new dimension of support applications can be 
made available to combatant commanders through help desk or accessed directly by the 
Commander in the field. 

d. Individuals 

Personnel are consistently identified as the most important resource in the 
military services. Many support services, such as relocation specialist, family support, finan- 
cial support and retirement services are required to achieve and maintain a high degree of 
morale by service members. These services may or may not be used by service members, 
but are made available, in case they do. It is believed that DoD personnel could also benefit 
from having access to decision technologies which assist them in making career decisions 
as well as personal decisions that influence their everyday life. Some of the services that are 
presently presented by clinics and seminars could be made available using the WWW and 
DDSN technology. This would allow personnel to obtain information and to use decision 
support services at their own convenience. This would reduce some of the overhead 
presently associated with these type of support activities. 

There are probably many other situations in which the DDSN concept could 
be employed within the DoD. Basically, any organization that requires assistance in making 


decisions could benefit from this technology. 
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E. CONCLUSIONS 

The DoD has generated a vision to effectively and efficiently use M&S to support a 
conglomerate of mission requirements. The integration of M&S to C4I will allow decision 
makers in a variety of functional areas to assess units performance and capabilities, develop 
and evaluate operational plans, and conduct what-if analysis in academic, training, and 


operational environments to achieve this vision, DOD must: 


& Develop a HLA architecture which will mandate common standards and 
conventions to be used in future M&S system and application development. 


® Re-engineer existing preferred stove pipe systems that are considered mission 
essential to function within the new architecture. 


® Identify requirements of functional areas to be supported. 
® Develop and maintain applications required to support all functional areas. 


e Develop and maintain the technical architecture and infrastructure to support 
the integration of M&S with C4]. 


This architecture will allow chosen sites the use of selected and predetermined M&S 
applications to support missions identified by functional user requirements. While the 
architecture provides a mechanism to share M&S resources, it also creates a high level of 
system and application maintenance overhead. A MSCC will be required to assist users and 
coordinate usage. Additionally, all sites will be required to maintain a suite of software that 
is required for the transfer of information and to achieve interoperability between applica- 
tions. 

While the goals of the DoD vision and the concepts of a DDSN are the same, the 
target environment is different. DoD’s vision provides a designated set of users within 
functional areas, a predetermined set of models and simulations. [The DDSN idea allows 
all users of a common network access to an undetermined amount of decision technologies; 


limited by availability only]. Use of the DoD M&S network would require users to have 
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access to a designated platform which is configured for use of the M&S network. The 
DDSN concept allows any user with a personal computer to become an instance of an 
application running on a super computer with limited software requirements. 

The dynamic scenarios which components of the DoD support will require flexibility 
in the type of applications made available. The COE envisioned will provide applications 
to support decision makers with well defined and understood problem situations. A 
mechanism, such as that proposed by the JTF/ATD will be required to allow for the 
expedient development and interface of modules to assist decision makers in diverse and 
unknown situations. The DDSN architecture could compliment the simulations and models 
available within the M&S COE; allowing immediate access and use of models and 


simulations that may only be used sporadically, under unique situations. 
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VI. CONCLUSIONS 


A. THESIS SUMMARY 

This thesis introduced a new concept for integrating decision support technologies 
with global computer networks. The main objective of this concept is to provide decision 
support technologies to users of a global heterogeneous network with minimal standards and 
conventions dictated. The architecture and infrastructure of the DDSN provides documen- 
tation for further research, development, and implementation of this concept. The 
architecture and infrastructure identified in this thesis is based on the ideas of the WWW and 
will continue to evolve. 

The DoD also realizes that the integration of M&S with computer networks will 
provide for better use of M&S resources. They envision integrating M&S with C4I to 
increase availability, shareability, and reuse of M&S applications between a variety of 
functional areas. Their infrastructure to achieve this is based on a COE and mandating 
standards and conventions in the development of M&S applications. This infrastructure will 
guarantee interoperability between applications, but will restrict access to those applications 
identified by functional area requirements. The DDSN infrastructure can augment the DoD 
infrastructure by allowing users to use decision technologies developed outside of the COE. 


This will allow users to access technologies that may only be required for a specific situation. 


B. AREAS OF FURTHER RESEARCH 

The general nature of this thesis has resulted in identifying a variety of topics of 
which will require further research. Further research of the DDSN concept falls into three 
general categories: further development of the DDSS, identifying or developing applications 
to demonstrate the functionalities of the architecture, and developing a plan for managing the 
DDSN infrastructure. 

1. Future Development of the DDSS 

Decision Net, the DDSS prototype, has proven the ability to execute independent 
~ technologies remotely using WWW technology. The next development stage of the DDSS 
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will allow for automatic registration and interactivity between exclusive applications. Before 
this software can be developed, a taxonomy of decision technologies needs to be established 
and an algorithm to classify decision technologies must be created. A determinant factor in 
user satisfaction of the DDSN will be the ability to find the correct application for a given 
situation. The taxonomy and classification mechanism will be essential in developing an 
intelligent search agent to locate applications best suited to support a users problem 
definition. 

The development of the middleware which provides for the translation of inputs and 
outputs to achieve interoperability is based on theory and a proof of concept is required. 
Further research must prove PFDL and address the limitations of the language. Intelligent 
software agents need to be developed which will allow for the expedient translation of data 
to the new data type. Methods to store, identify, translate, and deliver these data objects 
must be developed and implemented. 

2. Developing Applications to Demonstrate DDSN Potential 

Users of the DDSN will require confidence of the applications made available, 
providers must also realize the benefits of this technology before they will want to register 
their technologies. An assortment of killer applications, which illustrates the benefits to all 
users and capabilities of the network needs to be identified and implemented. These 
applications should be real world applications that can be used within a functional area. A 
possible area of interest may be within command and control. 

3. Develop a Management Plan for the DDSN and the DDSS Infrastructure 

The management facet of the DDSN needs to be researched since the DDSN can be 
considered as a service oriented business. As such, a management plan to ensure satisfaction 
of service is required. The management plan should address all legal, financial, and 
regulatory concerns of the system, identify performance measures, optimal system 
configurations to meet those performance measures, and quality control methods employed 
to assure satisfaction. 

In developing the management plan, potential barriers will need to be addressed and 


resolved. An example is the issue of software licensing of distributed applications. Will new 
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legislation need to be introduced to allow for multiple users to access and use a software 
application running on the software owners machine? Charge back mechanisms must also 
be identified and a method to monitor usage, initiate billing, and receipt of payment from 
users must be established. Additionally the system must provide for a certain degree of 
performance standards (security, reliability, and availability) to all users of the network. 

Server and network configuration management issues need to be addressed, metrics to 
measure performance standards identified, and methods to provide security of corporate data 


established. 


C. CONCLUSIONS 

This thesis established proof of concept for the distribution of decision support 
technologies to users of a global network. The initial architecture and proposed infra- 
structure identifies the DDSS as the link pin of the DDSN idea. The DDSS provides the 
majority of functions which allow for access, execution, and interoperability between all 
entities of the network. The DDSN concept is dependent heavily on the technical develop- 
ment of the DDSS, however it is also dependent on developing an electronic market of 
decision support services. Consumers and providers of decision technologies must want to 
use the services of this market. Government interest in NII, and the expodential growth of 
the WWW suggest that electronic commerce is the wave of the future. The DDSN concept 
is one way in which the decision sciences can ride this wave. 

The initial architecture develops the DDSN concept as a global resource, used by all 
who have access to the Internet, however, it is felt that the concept is also suitable at an 
enterprise level. A computer integrated enterprise is based on the integration of information 
and decision logic to achieve functional synergies. A DDSN would provide access to the 
same corporate data as well as decision aides required to process this information. Decision 
makers could use the same decision aides which would enhance decision logic. Each 
corporation would maintain a DDSS which would also allow for accountability, user 


availability, and reduced maintenance cost of decision technologies for the corporation. 
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The DoD evidently expects the use of M&S to increase readiness and reduce wasted 
assets in the DoD. DoD has traditionally used simulations in war gaming, virtual weapon 
system trainers, and live simulations in a training environment. Models and decision support 
systems have traditionally been developed to support specific requirements. DoD is in the 
process of building a M&S network which will meet the known requirements of five func- 
tional areas and allow for interaction between all. It is felt that the DDSN idea can augment 


this network by making additional technologies available to all users of DoD. 
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GLOSSARY (DEFINITIONS) 


Architecture: 


Consumer: 


Distributed Decision 
Support Network (DDSN): 


Distributed Decision 
Support Server (DDSS): 


Infrastructure: 


Network: 


Provider: 


The structure of components in a system, their inter- 
relationships, and principles and guidelines governing their 
design and development over time. 


Any person or organization who is in the market for 
computational decision support services. 


A computer network which allows for the distribution of 
decision support applications over a global network; a DDSN 
consist of a computer network, providers of decision 
technologies, consumers of decision technologies, and the 


(DDSS). 


Provides the mechanisms which allow users to register, search 
for, connect to, and execute a decision technology. The 
DDSS is comprised of hardware, software, and the personnel 
assets which allows for the functionality of the DDSN. 


Resources used to achieve desired functionalities of a system 
(Personnel, hardware, software, communications). 


Allows for the physical transfer of data and the seamless 
interaction between different types of platforms. 


Organizations, developers and/or individuals who desire their 
decision technology to be executable over the network. 
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APPENDIX A. ENABLING TECHNOLOGIES 


A variety of technologies will have significant impact on the development of the DDSN 
concept. This appendix identifies technologies by discussing general trends and briefly 
discussing each technology. 


A. TRENDS 


The use and performance of information systems technologies have increased by 30- 
50% percent per annum over the past two decades. If this continues more than 1000 MIPS 
and hundreds of megabytes of memory in workstations, supported by billions of bytes of 
local storage will be available at the same cost of today’s high-end workstations. 


Communications bandwidth capacity exceeding 1+ Gbps is available today. This will 
give the consumer the bandwidth on demand required for high resolution multimedia. 


Information search and retrieval capabilities available in client/server environments 
are allowing consumers to find the information available over the global networks. The 
increase in demand from users for new tools to expedite information retrieval will be 
eventually led to interconnectivity and interoperability of data and software applications. 
Distributive Collaborative Planning tools will be the norms on most desktop environments. 
This will allow for interaction for planning and telecommunications. 


Mass storage capacities will continue to increase with decreased cost. Today, hard 
disk drive mass storage can be purchased at $1 per megabyte (MB). New storage 
technologies will emerge, lowering cost. 


Multi-level security (MLS.) continues to be a serious topic and will require further 
research. Some organizations will have accredited MLS systems. A US Government-wide 
MLS policy does not exist and will probably not be developed for some time. Providing 
security of information will be a necessity for service providers of a global network. 


The use of Object-Oriented Technologies (OOT) will expand into software 
development, operating systems, and database management. 


The use of Virtual Reality is becoming popular in developing user interfaces and 
modeling techniques. Interactive simulations allow for geographically distributed users to 
interface and to influence the environment for which they are acting. This technology is 
available presently to high end computing systems and require dedicated networks. The 
Virtual Reality Modeling Language (VRML) vision is to bring interactive 3D to the Internet 
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via the WWW. This may influence the use of 3D models and simulations at a lower level 
of computing. 


B. COMMUNICATIONS 


Significant advances in networking and long-haul communications technologies are 
expected. Local Area Networks (LANs), such as the 10 Megabits per second (Mbps) 
Institute of Electrical and Electronics Engineers (IEEE) 802.3 Ethernet and 16 Mbps IEEE 
802.5 token ring are commodity items available worldwide today. Public packet-switched 
Wide Area Networks (WANs) are operated in all industrialized countries. Large private 
networks in both the Government and commercial sectors are starting to use T1 (1.544 
Mbps) and T3 (45 Mbps) transmission circuits. Asynchronous Transfer Mode (ATM), and 
Synchronous Optical Network (SONET) will dominate both Government and public-sector 
communications networks. 


C; INFORMATION SYSTEMS 


Information systems are encomposing more users. Workstations and personal 
computers are now interconnected allowing access to better resources and sharing of 
information. Client/Server technology and the Distributed Computing Environment (DCE) 
are allowing for the distribution of data, display, and functional processing throughout the 
network. Client server technology is currently being implemented, while DCE is still 
immature and in the experimental stages. 


D. SECURITY 


Several security technologies can be used to provide information security services 
such as data confidentiality, data integrity, access control, identification and authentication, 
nonrepudiation, and availability. Service providers will have to guarantee security of 
consumers data if electronic commerce will be accepted by the populous general. MLS will 
be required to achieve true interoperability between users with different security 
classifications; both data and information systems. Labeling, storage, and processing of 
data, write up technologies, and separation of environments make MLS a hard nut to crack. 


E. OBJECT-ORIENTED TECHNOLOGIES 


Object-oriented technologies (OOT) are emerging as a group of technologies that will 
allow information systems to be reusable, interoperable, and portable. The technology is 
demonstrating significant cost and time savings in commercial and government trials, 
including military. The emerging work from these efforts form the basis for the full life cycle 
of software; they support system development and data management. Areas of OOT that 
will probably effect the development of the DDSN concept are : object-oriented analysis and 
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design (OOA/OOD), object-oriented operating systems (OOOs), object-oriented program- 
ming languages (OOPLs), object-oriented database management systems (OODBMSs), and 
Object Management. 


F. COMPRESSION TECHNIQUES 


Technologies exist to compress digital images and video to a fraction of their original 
size for storage and transmission. Methods that achieve high compression ratios remove 
some data to achieve smaller data files. The use of simulations for playback or possibly 
interactive simulations will require large compression ratios. The Virtual Reality Modeling 
Language (VRML) presently uses compression technology to transmit 3D worlds to users 
of the Internet. The resolution required by the application and the user will determine the 
type of compression required. Some technologies are “lossy” because the decompressed 
images are reduced in size. Lossless methods also exist where data file size is reduced 
during compression but none of the data is lost when the file is decompressed. 


G. VIRTUAL REALITY MODELING LANGUAGE 


VRML is a draft specification for adding 3D data to the Internet via the WWW. The 
current vision is to allow for a 3D browser to search, travel and interact with major 
repositories of information on the WWW. This proposal would allow Virtual Reality (VR) 
environments to be incorporated into the World Wide Web, thereby allowing users to"walk" 
around and visualize actual environments. VRML is a logical markup language that will be 
used for non-proprietary platform independent VR. It is believed VR will become an 
increasingly important medium and will be accessible due to increases in bandwidth and 
high end computing assets availability. This mechanism would allow users to share VR 
models and possibly interactive simulations on a global basis from desk top computers. 
Presently, VRML technology allows a user to build a world with hyper text links embedded 
to allow a user to connect to another world or another information repository. This is a low 
end system which allows movement through cursor keys. This technology has great potential 
for global interactive 3D environments. 
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APPENDIX B. SADT/IDEFO0 MODEL OF A DDSS 


A. PREFACE 


A Structured Analysis and Design Technique (SADT)° commonly called IDEF 0 was 
used to model the activities and the interrelations of these activities required to distribute 
decision support technologies. This model is nothing more than a tool to help the author 
better understand and describe the requirements and relationships of the processes of the 
Distributed Decision Support Server (DDSN). The system in focus for the model is the 
DDSS. 


An IDEF 0 model has a single subject. The subject of this model is “Provide 
Distributed Decision Support Technologies.” Obtaining the correct subject is critical in the 
development of the model. It must focus on understanding the system. The boundaries of 
the system, what is inside and what is outside the system, must be clearly defined. The 
subject must be bounded to concentrate attention on the system being described and avoid 
the introduction of external environmental entities. 


An IDEF 0 model has one viewpoint or perspective. The viewpoint of this model is 
that of the system administrator of the DDSN. A viewpoint can be a person, place, or thing 
of the system in which if replaced, could watch the overall operation of the system. Different 
views will yield different descriptions of the system being modeled. 


The IDEF 0 software BPWIN® was used to develop the top-down diagrams. The 
diagrams start with a general diagram and are decomposed into more specific diagrams 
which outline the activities of a specific system. The collections of these diagrams and the 
natural language obtained from user descriptions compose the IDEF 0 model. The diagrams 
use boxes, which represent functions or activities and arrows which represent 
interconnections between the boxes. The boxes are numbered alphanumerically and 
represent the origin and the path used in the development of the model. A-0 is the top level 
diagram commonly called the context diagram. AO is the decomposition of the context 
diagram. This diagram will contain 3-6 boxes which will be labeled with a single numeral 
(1, 2, 3). When these boxes are decomposed, they will become the Al, A2, A3 diagrams. 
This process continues through the last level of the model. The arrows identify information 
or data needed to carry out the functions or activities. An arrow coming into a box from the 


The explanation of the SADT/IDEF 0 business processing and enterprise modeling is 
summarized from Marcia, David A., and McGowen, Clement L., IDEF 0/SADT Business 
Process and Enterprise Modeling, Electic Solutions Corp, San Diego, 1993. 


°BPWIN 1.50b is a beta version produced by Logic Works. 
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left, is input data, while an arrow coming out of a box on the right side is output data. An 
arrow coming from the top shows a control order while an arrow coming in from the bottom 
shows a physical resource or mechanism required to do a function. 


Identifying inputs, outputs, controls, mechanisms and a brief description of the functioning 
will explain each box of the model of that activity. The purpose of explaining each box is 
to describe how each activity functions independently and the interaction required with other 
activities of the system. 


B. NODE A-0: CONTEXT DIAGRAM OF PROVIDE DISTRIBUTED 
DECISION SUPPORT TECHNOLOGIES (Figure B-1) 


Activity Number:  A-0 


Activity Name: PROVIDE DISTRIBUTED DECISION SUPPORT 
TECHNOLOGIES 

Input Name: Consumers Info, Decision Technology Info, Metadata 
Requirements, Providers Info 

Output Name: Billing, Distributed Decision Technology, Management 
Reports, Registration Information, Registration Verification 

Control Name: Legal, Protocols, Validation& Verification Criteria 


Mechanism Name: Information System, Personnel 


Activity Definition: The Distributed Decision Support Network (DDSS) is the 
main focus of the system. The DDSS is a conglomerate of servers which interact to provide 
functionalities required to distribute decision technologies. The main server is a Hyper Text 
Transfer Protocol (HTTP) server which is called the Distributed Decision Support Server 
(DDSS). The DDSS will interact with other types of servers (SMTP, FTP, DBMS) to 
provide for registration, validation and interface of decision technologies to all users of the 
network. The protocols control the interface and functioning of these servers of the 
information system. 


The providers, consumers, and the technologies interfaced to the DDSN are 
considered external entities of the system. The system requires a variety of information from 
these entities to provide for the user/system interface and the actual access and execution of 
decision technologies. This information is controlled by the metadata requirements 
established by the DDSN, legal obligations to protect private information established by the 
U.S. government, and Validation and Verification criteria established by the decision 
sciences to ensure the technology provides the support advertised. 


The main output of this system is an interface to a “Distributed Decision Tech- 
nology.” The technology is physically outside of the system but the interface which allows 
for the technology to be accessed and executed is considered an output of the system. Other 
outputs are tools that are required for the management of the system. These include a variety 
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of reports, registration information, and billing or usage information. Registration verifi- 
cations are sent to users of the system upon successful registration as a provider of a decision 
technology or a consumer of the system. At this time, the distribution of decision 
technologies is a semi-automated information system which requires personnel to accomplish 
validation and management activities. Some of these functions will be automated, however 
this model identifies the personnel required at this point in time. 

C. ARROW DEFINITIONS 

1. Inputs 


Things such as data or information which is used or transformed by the activity. 
Arrows come into the activity from the right. 


a. Providers Info 


Information about the provider which is needed to register the provider with 
the DDSS. 


b. Consumers Info 


Information about the consumer which is required to register the consumer 
as a user of decision technologies. 


c. Decision Technology Info 

Information about the decision technology which is to be registered with the 
DDSS. Information will include the metadata, validation and verification criteria unique to 
the application, and all interface requirements. 


d. User Request 


Upon registration users (providers and consumers) will desire different 
services from the DDSS. These services will require the user to initiate a process or activity. 


Ze Outputs 


Represent the things for which the activity has transformed or created. Arrows leave 
the activity from the right. 
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a. Management Reports 


Reports used by the DDSS staff to identify users of the system and 
technologies available on the DDSS. 


b. Registration Information 


This is the users information which has been validated and is available within 
the DDSS databases. 


Cc. Registration Verification 
Notification to the user that the user registration process has been completed. 
d. Distributed Decision Technology 


A technology that has been successfully registered, validated, and interfaced 
for use by registered consumers of the DDSN. 


é. User Statistics 
Any and all information about the use of the DDSS. 
3. Mechanisms 


Represent the physical aspects of an activity or how activities are realized. Arrows 
come into the activity from the bottom of the activity. 


a. Information System 

A series of servers that allow for the registration of users, storage of 
information, search of available technologies, and execution of those technologies in an open 
environment. | 


b. Personnel 


The DDSS staff required to facilitate the registration, verification, and 
interface activities. 


4, Control 


These are things that constrain the functioning of the activities. Arrows come into the 
activity from the top. 
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a. Protocols 


Set of established rules between the environment and activities and between 
activities which allow for shareability and execution of task between the activities. 


b. Legal 


Legislation which identifies the rights of individuals and mandates 
responsibilities by those providing services. 


C. Validation and Verification Criteria 


Criteria established by the decision sciences in the classification and 
functioning of decision support application. 


d. Metadata Requirements 


Information required to interface and classify a decision technology. 


D. NODE A0: DECOMPOSITION OF CONTEXT DIAGRAM - PROVIDE 
DISTRIBUTED DECISION SUPPORT TECHNOLOGIES (Figure B-2) 


Activity Number: 
Activity Name: 


Input Name: 
Output Name: 


Control Name: 
Mechanism Name: 


Sub-activities: 


Activity Definition: 


A0 

PROVIDE DISTRIBUTED DECISION SUPPORT 
TECHNOLOGIES 

Consumers Info, Decision Technology Info, Metadata 
Requirements, Providers Info 

Billing, Distributed Decision Technology, Management 
Reports, Registration Information, Registration Verification 
Legal, Protocols, Validation& Verification Criteria 
Information System, Personnel 


Al - REGISTER USERS 
A2 - VALIDATE TECHNOLOGY 
A3 - INTERFACE TECHNOLOGY 


Same as A-0 
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E. NODE Al: DECOMPOSITION OF REGISTER USERS (Figure B-3 through 


B-6) 


Activity Number: 
Activity Name: 
Input Name: 


Output Name: 
Control Name: 


Mechanism Name: 
Sub-activities: 


Activity Definition: 


Al 

REGISTER USERS 

Consumers Info, Decision Technology Info, Metadata 
Requirements, Providers Info 

Registered Consumers Info, Registered Providers Info, 
Registered Technologies Info, Registration Verification, Users 
Reports 

Legal, Protocols 

Personnel 

All - PRODUCE FORMS AND SCRIPTS 

Al12 - UPDATE DATABASE 

Al13 - PRODUCE REGISTRATION VERIFICATION 


This activity requires the system to capture user data, to 


include: Consumer registration information, provider registration information, and 
technology metadata. The initial registration of users and providers is done on-line via 
HTML forms. The information is then captured and stored in the DDSN database by the use 
of a scripting language. Updating the database invokes another script which produces a 
registration verification. This verification is in the form of E-mail and is automatically 
generated. The metadata required to register a decision technology involves the capture of 
a variety of information. The system allows for the capture of this information in the same 
way users are registered. An optional off-line registration form can also be used via E-mail. 
This information will be captured in the same format (HTML) and be used to update the 
database as if it were captured on-line. 


Activity Number: 
Activity Name: 
Input Name: 
Output Name: 
Control Name: 
Mechanism Name: 
Sub-activities: 


Activity Definition: 


All (Figure B-4) 
PRODUCE FORMS/SCRIPTS 


Input Forms, Input Scripts 

HTML 3.0, SMTP, Metadata Requirements 

HTTP Server, Programmers 

Al11 - BUILD FORMS/SCRIPTS 

A112 - VALIDATE FORMS/SCRIPTS 

A113 - INTERFACE FORMS/SCRIPTS TO NETWORK 


This activity develops the forms and scripts required to capture 


user information. The metadata requirements are used to control what is to be captured by 
the forms. The programmers develop a set of forms to capture the pertinent information and 
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a series of scripts to update databases and initiate registration verification. The forms and 
scripts are built, validated, and interfaced to the network during this activity. 


Activity Number: 
Activity Name: 
Input Name: 
Output Name: 
Control Name: 
Mechanism Name: 


Activity Definition: 


Aill 

BUILD FORMS/SCRIPTS 
Metadata Requirements 
HTML forms, Scripts 
HTML 3.0, SMTP 

HTTP Server, Programer 


Programmers build forms using an HTML editor or word 


processor. Scripts are built using Perl scripting language. There are a variety of scripting 
languages, however Perl is used in this system. 


Activity Number: 
Activity Name: 
Input Name: 
Output Name: 
Control Name: 
Mechanism Name: 


Activity Definition: 


A112 

VALIDATE FORMS/SCRIPTS 

HTML forms, Scripts 

Validated HTML forms, Validated Scripts 
HTML 3.0, SMTP 

HTTP Server, Programer 


Forms and scripts are validated to ensure that they capture the 


desired information, update DDSN databases, and invoke verification process as described 


in Al. 


Activity Number: 
Activity Name: 
Input Name: 
Output Name: 
Control Name: 
Mechanism Name: 


Activity Definition: 


All3 

INTERFACE FORMS/SCRIPTS TO NETWORK 
Validated HTML forms, Validated Scripts 

Input Forms, Input Scripts 

HTML 3.0, SMTP 

HTTP Server, Programer 


The validated forms and scripts are then installed within the 


DDSN. The interface between the DDSS, DBMS and SMTP server is tested and the forms 
and scripts comprise the registration module of the DDSN. 


Activity Number: 
Activity Name: 
Input Name: 


A12 (Figure B-5) 

UPDATE DATABASE 

Consumers Info, Decision Technology Info, Providers Info, 
Verification Flag 
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Output Name: 


Control Name: 


Sub-activities: 


Activity Definition: 


Registered Consumers Info, Registered Consumers Rpt, 
Registered Providers Info, Registered Providers Rpt, 
Registered Technologies Info, Registered Technologies Rpt 
DBMS, Input Forms, Input Scripts 


A121 - ADD NEW INFORMATION 
A122 - MODIFY EXISTING INFORMATION 
A123 - DELETE INFORMATION 


This activity allows for the addition of new users and 


technologies, modification of user and technology information and the deletion of registered 
users and technologies to the DDSN database. The DBMS provides the management tools 
to the staff of the DDSN in the form of reports, statistics of use, and all information 
pertaining to users and technologies registered with the DDSN. The database is updated 
during online registration through the use of HTML forms and Perl scripts. The database is 
accessed by the users through the HTTP server allowing for a heterogeneous interface. 


Activity Number: 
Activity Name: 
Input Name: 
Output Name: 
Control Name: 
Mechanism Name: 


Activity Definition: 


A121 

ADD NEW INFORMATION 

Consumers Info, Decision Technology Info, Providers Info 
Added, New Consumer Rpt, New Prov Rpt, NewTech Rpt 
DBMS, Input Forms, Input Scripts, Legal 

Database Server, HTTP Server 


This activity allows for all registered users of the DDSN to add 


new information to the DDSN database. 


Activity Number: 
Activity Name: 
Input Name: 
Output Name: 


Control Name: 
Mechanism Name: 


Activity Definition: 


A122 

MODIFY EXISTING INFORMATION 

Consumers Info, Decision Technology Info, Providers Info 
Modified, Registered Consumers Info, Registered Consumers 
Info 

DBMS, Input Forms, Input Scripts 

Database Server, HTTP Server 


This activity allows for all registered users of the DDSN to 


modify existing information about themselves or a technology which they have registered. 


Activity Number: 
Activity Name: 
Input Name: 


A123 
DELETE INFORMATION 
Consumers Info, Decision Technology Info, Providers Info 


70 





Output Name: Deleted, Deleted Consumer Rpt, Deleted Prov Rpt, Deleted 
Tech Rpt, Registered Technologies Info 

Control Name: DBMS, Input Forms, Input Scripts 

Mechanism Name: Database Server, HTTP Server 


Activity Definition: This activity allows for all registered users of the DDSN to 
delete themselves as registered users and to delete information which they have provided 


about a registered technology. 


Activity Number: Al13 (Figure B-6) 


Activity Name: PRODUCE REGISTRATION VERIFICATION 

Input Name: Registered Consumers Info, Registered Providers Info, 
Registered Technologies Info 

Output Name: Consumer, Provider, Technology, Verification Flag 

Control Name: Input Scripts, SMTP, SMTP 

Mechanism Name: Email Server, HTTP Server 

Sub-activities: A131 - PROCESS CONSUMER VERIFICATIONS 


A132 - PROCESS PROVIDER VERIFICATIONS 
A133 - PROCESS TECHNOLOGY VERIFICATIONS 


Activity Definition: This activity provides an e-mail message to the user upon 
completion of registration, verification, and validation of the user and/or the technology. 
This action completes the initial registration process for users of the system. Users 
registering themselves as a consumer or provider obtain an immediate reply if they have 
successfully registered. An on-line message via the clients WWW browser is sent if the 
registration was unsuccessful. The registration of a decision technology requires an 
extensive validation and validation process. The provider of a technology will be sent an 
interim notice that the information about the decision technology has been received and that 
the validation and verification process has been initiated. Registration of a decision 
technology is not completed until the technology has been validated by A2 VALIDATE 
TECHNOLOGY. 


Activity Number: A131 


Activity Name: PROCESS CONSUMER VERIFICATIONS 
Input Name: Registered Consumers Info 
| Output Name: Consumer Verification 
| Control Name: HTTP, Input Scripts 


Mechanism Name: HTTP Server 





| . Activity Definition: This activity generates an email message to the user that 
confirms their registration. 
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Activity Number: A132 


Activity Name: PROCESS PROVIDER VERIFICATIONS 
Input Name: Registered Providers Info 

Output Name: Provider Verification 

Control Name: HTTP, Input Scripts 


Mechanism Name: HTTP Server 


Activity Definition: This activity generates an E-mail message to the user that 


confirms their registration as a provider of a decision technology. 


Activity Number: A133 


Activity Name: PROCESS TECHNOLOGY VERIFICATIONS 
Input Name: Registered Technologies Info 

Output Name: Technology Verification 

Control Name: HTTP, Input Scripts 


Mechanism Name: HTTP Server 


Activity Definition: This activity generates an E-mail message to the user that 


confirms the receipt of information pertaining to the technology and that the technology is 
being verified and the interface 1s being investigated. 


user. 


Activity Number: A134 


Activity Name: MAIL VERIFICATION 

Input Name: Consumer Verification, Provider Verification, Technology 
Verification | 

Output Name: Consumer, Provider, Technology, Verification Flag 

Control Name: SMTP 


Mechanism Name: Email Server 


Activity Definition: This activity delivers the appropriate E-mail message to the 


NODE A2: DECOMPOSITION OF VALIDATE TECHNOLOGY (Figure B-7) 


Activity Number: A2 


Activity Name: VALIDATE TECHNOLOGY 

Input Name: Registered Technologies Info 

Output Name: Validated Technology, Validation& Verification Reports 
Control Name: Legal, Protocols, Validation& Verification Criteria 


Mechanism Name: Information System, Personnel 
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Sub-activities: A21 - CLASSIFY DECISION TECHNOLOGY 
A22 - RUN APPLICATION 
A23 - VERIFY APPLICATION OUTPUTS 
A24 - PRODUCE V&V REPORTS 


Activity Definition: This activity is a semi automated procedure to ensure the 
correctness and accredited the decision technology for use. Intelligent agents and human 
specialist will verify the model description and classify accordingly. The application will 
be run against parameters given by the provider. Upon verification, validation, and 
accreditation, reports are archived and the technology is ready to be interfaced to the DDSN. 


Activity Number: A21 


Activity Name: CLASSIFY DECISION TECHNOLOGY 
Input Name: Registered Technologies Info 

Output Name: Classified Technology Info 

Control Name: Legal 


Mechanism Name: Decision Support Specialist 


Activity Definition: Activity categorizes the application. The registered tech- 
nologies info is used to identify the type of application and the functional area that it can be 
used in. The application 1s given an appropriate classification which will be used for 
indexing and cross referencing. 


Activity Number: A22 


Activity Name: RUN APPLICATION 

Input Name: Classified Technology Info 

Output Name: Application Outputs 

Control Name: Protocols, Validation& Verification Criteria 


Mechanism Name: Decision Support Specialist, Information System 
Activity Definition: The application is run remotely to validate operation 


Activity Number: A23 


Activity Name: VERIFY APPLICATION OUTPUTS 
Input Name: Application Outputs 

Output Name: Report Data, Validated Technology 
Control Name: Protocols, Validation& Verification Criteria 


Mechanism Name: Decision Support Specialist, Information System 


Activity Definition: Output of the application is compared with the expected given 
at registration to ensure correctness 
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Activity Number: A24 


Activity Name: PRODUCE V&V REPORTS 

Input Name: Application Outputs, Classified Technology Info, Report Data 
Output Name: Validation& Verification Reports 

Control Name: Validation& Verification Criteria 


Mechanism Name: Decision Support Specialist 


Activity Definition: Reports are generated for validation, verification, and accredit- 
ation process for each application registered and accepted for use. 


G. NODE A3: DECOMPOSITION OF INTERFACE TECHNOLOGY 


(Figure B-8) 

Activity Number: A3 

Activity Name: INTERFACE TECHNOLOGY 

Input Name: Registered Technologies Info, Transaction Request 
Output Name: System Statistics, , Distributed Decision Technology 
Control Name: Legal, Protocols, Validated Technology 

Mechanism Name: Information System, Personnel 

Sub-activities: A31 - IDENTIFY INTERFACE REQUIREMENTS 


A32 - BUILD INTERFACE 
A33 - DISTRIBUTE DECISION TECHNOLOGY 
A34 - MONITOR USE OF TECHNOLOGY 


Activity Definition: Allows users to access registered decision technologies by 
providing a common interface to the provider of the decision technology. The interface will 
be dependent on the type of technology and the type of servers computer assets available at 
the providers site. The registered technologies info identifies all inputs required and outputs 
of the technology. If the provider is classified an independent technology, the interface is 
nothing more than an HTML form which will reside within the DDSS file directory 
structure. If the technology is exclusive a series of scripts and HTML forms will interface 
the application with the HTTP server at the DDSS. The provider must provide a 
combination of servers to allow for data transfer from the consumer, output back to the 
consumer, and a DNS to allow activation of application possibly through a transparent Telnet 
session. This interface allows for transparent connection, data transfer, and execution of 
technology. A feed back activity is also required to monitor the use of any given technology. 
This is required for billing of both consumer and providers and to track resource 
requirements. 


Activity Number: A31 


Activity Name: IDENTIFY INTERFACE REQUIREMENTS 
Input Name: Registered Technologies Info 
Output Name: Type of Interface 
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Control Name: Legal, Protocols, Validated Technology 
Mechanism Name: Decision Support Specialist, Programer 


Activity Definition: This activity identifies the type of technology that has been 
registered and verifies the correctness of data given at registration. If data is incomplete, the 
POC is contacted and the information is solicited. After all information is available , the data 
is sent to the Build Interface activity for automatic setup of the application to the DDSN. 


Activity Number: A32 


Activity Name: BUILD INTERFACE 

Input Name: Registered Technologies Info 

Output Name: Specific Technology Interface 

Control! Name: Protocols, Type of Interface, Validated Technology 


Mechanism Name: Decision Support Specialist, HTTP Server, Programer 


Activity Definition: Presently a manual process, but automation is envisioned. A 
series of CGI scripts and HTML documents make up the interface. An exclusive technology 
will have the files sent to the providers server. An HTML file summarizing the input data 
will also be maintained at the DDSS. This file is the application entry file for consumers of 
the network. The final product of the build interface activity is a distributed decision 


technology. 
Activity Number: A33 
Activity Name: DISTRIBUTE DECISION TECHNOLOGY 
Input Name: Registered Consumers Info, Registered Providers Info, 
Registered Technologies Info, Transaction Request 
Output Name: Distributed Decision Technology 
Control Name: Protocols, Technology Interface 


Mechanism Name: Decision Support Specialist, HTTP Server, Programer 


Activity Definition: This a control activity which allows registered users to use 
registered decision technologies. The login of users is also done at this activity. A good 
analogy here is a menu. The user is provided a list of options (register, login, use a 
technology), through a transaction request the appropriate activity within this activity is 
initiated. 


Activity Number: A34 





Activity Name: = MONITOR USE OF DECISION TECHNOLOGY 
Input Name: Distributed Decision Technology 

Output Name: Billing 

Control Name: Protocols 


Mechanism Name: HTTP Server, Programer 








Activity Definition: This activity tracks the usage of all users of the system. The 
output is system statistics which is sent to other processes such as billing and resource usage. 
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